Summary

Fixes #2501 — rtk dotnet test printed every failure twice on failing runs, inflating output by ~65% on the reported benchmark (the opposite of RTK's purpose). The regression was specific to failing runs; all-green runs were unaffected.

Root cause

In run_dotnet_with_binlog (src/cmds/dotnet/dotnet_cmd.rs), the failure branch prepended the entire raw stdout in front of the filtered output:

let output_to_print = if !command_success {
    if !stdout_trimmed.is_empty() {
        format!("{}\n\n{}", stdout_trimmed, filtered)  // ← prepends FULL raw stdout
    } ...
};

For test, that collides with the filter's own output. The raw stdout already prints every per-test failure inline (xUnit v3 / MTP), and format_test_output independently rebuilds the same failures into its Failed Tests: section — so each failure appeared once from the raw prepend and once from the structured section. build / restore source failures from a single place, so they never duplicated.

Fix

Extract the output-composition decision into a pure, unit-testable compose_dotnet_output. For test, the raw-stdout prepend is dropped only when the structured section is a complete substitute — i.e. failed_tests is non-empty and every failure carries detail. Otherwise the raw fallback is kept exactly as before, so nothing is ever lost:

The .all(|t| !t.details.is_empty()) guard (not .any()) preserves the raw message for name-only failures. Behavior is byte-for-byte identical to the previous inline logic in every case except the de-duplicated one.

Tests

The bug lived in the orchestration path, which had no test coverage (existing tests only exercised format_test_output in isolation). Added 8 regression tests covering every row above, including a benchmark-shaped case asserting the failure assertion string appears exactly once (the issue's measured proof: raw=5, buggy rtk=10, fixed=5).

Verification

cargo fmt --all -- --check   # clean
cargo clippy --all-targets   # No issues found
cargo test --bins            # 2216 passed; 0 failed; 8 ignored